Derive Document language name from languages.toml name key #3338
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This changes switches from deriving the language name from the `languages.toml` `scope` key to `name` (`language_id` in the `LanguageConfiguration` type). For the most part it works to derive the language name from scope by chopping off `source.` or `rsplit_once` on `.` but for some languages we have now like html (`text.html.basic`), it doesn't. This also should be a more accurate fallback for the `language_id` method which is used in LSP and currently uses the `rsplit_once` strategy. Here we expose the language's name as `language_name` on `Document` and replace ad-hoc calculations of the language name with the new method. This is most impactful for the `file-type` statusline element which is using `language_id`.
The `file-type` indicator element in the statusline was using `Document::language_id` which is meant to be used to for telling Language Servers what language we're using. That works for languages with `language-server` configurations in `languages.toml` but shows text otherwise. The new `Document::language_name` method from the parent commit is a more accurate way to determine the language.
the-mikedavis
force-pushed
the
md-refactor-language-id-and-name
branch
from
726bbef
to
1c2473f
Compare
thomasskk
pushed a commit
to thomasskk/helix
that referenced
this pull request
Sep 9, 2022
…tor#3338) * Derive Document language name from `languages.toml` `name` key This changes switches from deriving the language name from the `languages.toml` `scope` key to `name` (`language_id` in the `LanguageConfiguration` type). For the most part it works to derive the language name from scope by chopping off `source.` or `rsplit_once` on `.` but for some languages we have now like html (`text.html.basic`), it doesn't. This also should be a more accurate fallback for the `language_id` method which is used in LSP and currently uses the `rsplit_once` strategy. Here we expose the language's name as `language_name` on `Document` and replace ad-hoc calculations of the language name with the new method. This is most impactful for the `file-type` statusline element which is using `language_id`. * Use `Document::language_name` for the `file-type` statusline element The `file-type` indicator element in the statusline was using `Document::language_id` which is meant to be used to for telling Language Servers what language we're using. That works for languages with `language-server` configurations in `languages.toml` but shows text otherwise. The new `Document::language_name` method from the parent commit is a more accurate way to determine the language.
jdrst
pushed a commit
to jdrst/helix
that referenced
this pull request
Sep 13, 2022
…tor#3338) * Derive Document language name from `languages.toml` `name` key This changes switches from deriving the language name from the `languages.toml` `scope` key to `name` (`language_id` in the `LanguageConfiguration` type). For the most part it works to derive the language name from scope by chopping off `source.` or `rsplit_once` on `.` but for some languages we have now like html (`text.html.basic`), it doesn't. This also should be a more accurate fallback for the `language_id` method which is used in LSP and currently uses the `rsplit_once` strategy. Here we expose the language's name as `language_name` on `Document` and replace ad-hoc calculations of the language name with the new method. This is most impactful for the `file-type` statusline element which is using `language_id`. * Use `Document::language_name` for the `file-type` statusline element The `file-type` indicator element in the statusline was using `Document::language_id` which is meant to be used to for telling Language Servers what language we're using. That works for languages with `language-server` configurations in `languages.toml` but shows text otherwise. The new `Document::language_name` method from the parent commit is a more accurate way to determine the language.
herkhinah
pushed a commit
to herkhinah/helix
that referenced
this pull request
Dec 11, 2022
…tor#3338) * Derive Document language name from `languages.toml` `name` key This changes switches from deriving the language name from the `languages.toml` `scope` key to `name` (`language_id` in the `LanguageConfiguration` type). For the most part it works to derive the language name from scope by chopping off `source.` or `rsplit_once` on `.` but for some languages we have now like html (`text.html.basic`), it doesn't. This also should be a more accurate fallback for the `language_id` method which is used in LSP and currently uses the `rsplit_once` strategy. Here we expose the language's name as `language_name` on `Document` and replace ad-hoc calculations of the language name with the new method. This is most impactful for the `file-type` statusline element which is using `language_id`. * Use `Document::language_name` for the `file-type` statusline element The `file-type` indicator element in the statusline was using `Document::language_id` which is meant to be used to for telling Language Servers what language we're using. That works for languages with `language-server` configurations in `languages.toml` but shows text otherwise. The new `Document::language_name` method from the parent commit is a more accurate way to determine the language.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This changes switches from deriving the language name from the
languages.tomlscopekey toname(language_idin theLanguageConfigurationtype). For the most part it works to derivethe language name from scope by chopping off
source.orrsplit_onceon
.but for some languages we have now like html (text.html.basic),it doesn't. This should be a more accurate fallback for the
language_idmethod which is used in LSP and currently uses the
rsplit_oncestrategy.
Here we expose the language's name as
language_nameonDocumentandreplace ad-hoc calculations of the language name with the new method.
This is most impactful for the
file-typestatusline element which iscurrently using
language_id.It should also improve highlighting in popups for languages like html, erb, ejs, maybe solidity. For most languages there should be no functional changes from this PR.
Supersedes #2998
Should make #3273 more accurate